Havel canoe map (/havel) + north-up fix for all grid terrain scenes#100
Conversation
iceland_dem is the DEM→grid baker with no Garmin-tile dependency, so it's the right tool for skin scenes outside a Garmin IMG (e.g. the Havel canoe map). --skin (grid mode + a v2 demgrid) sinks the raw ESRI pixels into the grid as per-vertex colour (ver-9 photoreal skin) instead of the classified KIND palette; vertex i IS demgrid cell i, so the drape maps 1:1 with no resampling. Without --skin the bake is unchanged (ver-8 palette grid). Version log now reads the actual wire version from the header. Co-Authored-By: Claude Opus 4.8 <[email protected]> Claude-Session: https://claude.ai/code/session_012jEwwaT5JZ5x8qWvcnaMYC
…akes) The Havel canoe region (operator's next-10-days trip): bbox 12.246494,53.011917 .. 13.657894,53.539721 (upper-left / lower-right from satellites.pro), fetched keyless at z14/ds3 (Terrarium DEM + ESRI World Imagery, 5330 tiles, 0 missing). No Garmin tile exists for the region, so the bake is `iceland_dem --grid --skin` (the new flag from the previous commit): 5546×3498 = 19.4M verts, elev 12..174 m — flat lowland, so the scene's whole value is the ver-9 photoreal skin (lakes, channels, forest, reed banks). gz 69.3 MB in public/ (under GitHub's 100 MB blob limit; moving it to a q2 Release fetched on-demand is a tracked follow-up — the canyon precedent applies). Budget-LOD lands exactly on the ratified operating point: 19.4M full birdview → stride-2 = 4.85M ≈ the "20M is OK if LOD is 5 Mio" ask. Scene wiring is one manifest entry — /garmin/havel resolves through garmin_scenes and the dropdown auto-populates; zero cockpit code. Headless-verified on a 1.2M proxy bake: the lake district renders as real satellite (forest/field patchwork, lake chain, towns); HUD `verts 1.21M · full grid`. Co-Authored-By: Claude Opus 4.8 <[email protected]> Claude-Session: https://claude.ai/code/session_012jEwwaT5JZ5x8qWvcnaMYC
…vel route Three fixes from the operator's alignment check (Havel vs Google Maps): 1. NORTH-UP FIX (all ver-8/9 grid scenes — iceland, grand-canyon, havel — no rebake). The bake stores z = (lat−lat0)·M (north = +z) while the default aerial camera sits on the +z side (screen-up = −z), so every grid scene rendered N–S MIRRORED against a real map. Caught on the Havel: the Kölpinsee chain appeared SOUTH of the Müritz. The demgrid ground truth verified correct — display-side only. Fix in decodeGrid: negate zrow at read (positions + normals derive from the one table), emit the triangle winding flipped ((a,d2,b)/(b,d2,e)) so faces keep pointing +y, negate the concept-centroid z. Wire bytes + HHTL keys untouched. 2. WHITE BALANCE (operator: "the lighting is rather dull"). The ESRI imagery over Mecklenburg is hazy — measured white point p98 = 171/166/145. Bake-time per-channel p2→p98 stretch (→ 10..250) + saturation ×1.18 on the demgrid rgb, then rebake: the corrected colour is sunk into the grid once (the Diaprojektor model), not shader-guessed per frame. Havel asset replaced (72.7 MB gz). 3. /havel FIRST-CLASS ROUTE (like /ice): main.tsx Route + pathScene alias → garmin:havel + scene-menu alias so the dropdown shows it selected. First attempt missed the top-level router (the path fell through to the AIWAR cockpit) — caught by the headless shot. Headless-verified on a 1.2M proxy: Müritz + Kölpinsee at NW (north-up ✓), haze gone, /havel renders the terrain. Co-Authored-By: Claude Opus 4.8 <[email protected]> Claude-Session: https://claude.ai/code/session_012jEwwaT5JZ5x8qWvcnaMYC
|
Warning Review limit reached
Next review available in: 28 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (5)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Bugbot couldn't run - usage limit reachedBugbot is counted against Cursor usage for this user or team, and this run hit a usage or spend limit. A user or team admin can review and increase usage limits in the Cursor dashboard. (requestId: serverGenReqId_e18a1cdb-3ce7-45bc-922f-affe5ca04b8e) |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 987e3d578b
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| // appeared SOUTH of the Müritz). Negate z at decode — positions, normals and the | ||
| // row table all derive from this one table, and the winding below is emitted in | ||
| // the flipped order so faces keep pointing +y. Wire + HHTL keys are untouched. | ||
| for (let i = 0; i < Hf; i++) zrow[i] = -zrow[i]; |
There was a problem hiding this comment.
For any Garmin scene that has a garmin_drapes or garmin_contours entry, this z flip moves only the terrain: the DRP1 sidecars are still decoded in their original display frame and buildDrape/buildContours copy src[i + 2] unchanged, while garmin::drape bakes those points by sampling the pre-flip pos grid. As soon as a scene uses those existing sidecars, roads/rivers/contours will be north-south mirrored relative to the terrain; negate the overlay z in the same path or rebake/update the sidecar convention together with this decode change.
Useful? React with 👍 / 👎.
2 participants
The operator's next-10-days canoe region as a ver-9 photoreal scene — plus a display-orientation fix that corrects every grid terrain scene (iceland, grand-canyon, havel), caught during the Havel-vs-Google alignment check.
Havel canoe map —
/havel12.246494,53.011917 → 13.657894,53.539721(Mecklenburg lake district: Müritz, Müritz-Nationalpark, Uckermark), fetched keyless at z14/ds3 — Terrarium DEM + ESRI World Imagery, 5,330 tiles, 0 missing.iceland_dem --grid --skin(new flag): sinks the raw ESRI pixels into the ver-9 grid as per-vertex colour; vertex i IS demgrid cell i (1:1, no resampling).public/(under GitHub's 100 MB hard limit; Release-hosted on-demand fetch is a tracked follow-up). Budget-LOD: 19.4M full → stride-2 = 4.85M — the ratified "20M is OK if LOD is ~5M" operating point./havel(like/ice): top-level Route +pathScenealias + scene-menu alias. (First attempt missed the top-level router and fell through to the AIWAR cockpit — caught by the headless verification shot.)North-up fix (all ver-8/9 grid scenes, no rebake)
The bake stores
z = (lat − lat0)·M(north = +z) while the default aerial camera sits on the +z side (screen-up = −z) — so every grid scene rendered N–S mirrored against a real map. Found by the operator comparing the Havel render to Google (the Kölpinsee chain appeared south of the Müritz); the demgrid ground truth verified correct, so the bug was display-side only.Fix in
decodeGrid: negatezrowat read (positions + normals derive from that one table), emit the triangle winding flipped ((a,d2,b)/(b,d2,e)) so faces keep pointing +y, negate the concept-centroid z. Wire bytes + HHTL keys untouched — the merged canyon and iceland assets render correctly with no rebake.White balance (Havel)
The ESRI imagery over Mecklenburg is hazy — measured white point p98 = 171/166/145. Bake-time per-channel p2→p98 stretch (→10..250) + saturation ×1.18 on the demgrid rgb, then rebake: corrected colour sunk once (the Diaprojektor model), not shader-guessed per frame.
Verification
cargo build --release -p geo-hhtl --bin iceland_dem --features helix✓npx tsc --noEmit✓ ·npm run build✓/havelrenders the lake district north-up (Müritz + Kölpinsee at NW, matching ground truth + Google), haze gone, HUDverts 1.21M · full grid.Note on the reported React quarto-dev#185
The minified
Maximum update depth exceededfrom the branch deploy did not reproduce in a headless sweep of the terrain routes (desktop + mobile emulation, LOD/topo/features toggles, pick, orbit) — only environmental 404/connection noise. Static audit found no setState reachable from the render loop. Still open; tracked separately rather than blocking this PR.Follow-ups (carried)
/osmdual basemap (OSM ↔ satellite tiles).🤖 Generated with Claude Code
Generated by Claude Code